Electronic financial transaction with balancing invoice and credit items via page

ABSTRACT

An electronic transaction, in which a payment amount is deducted from a customer account and added to a provider account, is prepared in cooperation between an account computer and a browser-enabled customer computer. The account computer forwards invoice and credit information as well as calculation instructions in portions of a page to the customer computer. The customer computer interprets a first page portion with a browser to present different invoice items and credit items on a screen. A user selection of the invoice and credit items is received and then the payment amount is calculated by offsetting the amounts of the invoice and credit items with instructions in a second page portion. Thereafter, a response with the payment amount is returned to the account computer.

FIELD OF THE INVENTION

[0001] The present invention generally relates to the field of dataprocessing and, more particularly, the invention relates to computersystems, computer programs, and methods that support financialtransactions via browser pages.

BACKGROUND OF THE INVENTION

[0002] Service providers (e.g., private companies or governmentalorganizations) utilize computer systems to perform routine tasks, suchas billing/payment processes. Self-service scenarios can be convenientand provide cost savings not only for the provider, but also for thecustomer. For example, a customer can review invoice or bank accountsthat are presented by a browser interpreting a page.

[0003] The following documents are useful:

[0004] U.S. Pat. No. 6,175,823,

[0005] U.S. Pat. No. 6,336,098, and

[0006] U.S. Pat. No. 6,324,525.

[0007] For invoices with multiple items that either charge or deductto/from the customer's bank account, there is a technical task tocalculate balances and to communicate items to/from the customer withminimum load to the network.

SUMMARY OF THE INVENTION

[0008] In accordance with embodiments of the present invention, a methodis provided for preparing an electronic financial transaction, whereinprior to preparing the transaction, a first computer of a providerforwards invoice and credit information to a second computer of anaccount institution, and wherein after preparing, the second computerperforms the transaction by deducting a payment amount from a customeraccount and adding the payment amount to a provider account.

[0009] In the method, the step of preparing may comprise:

[0010] sending a page to a third computer to forward invoice and creditinformation in a first portion of the page and to forward calculationinstructions in a second portion of the page;

[0011] interpreting the first portion by a browser of the third computerto present different invoice items and credit items on a screen;

[0012] receiving from a user of the third computer a selection of atleast one invoice item and of at least one credit item;

[0013] calculating the payment amount by offsetting the amounts of theinvoice and credit items, thereby using the instructions in the secondportion; and

[0014] returning a response with the payment amount to the secondcomputer.

[0015] In the step of calculating, the payment amount may be evaluatedunder consideration of an available date of credit items. Further, inthe sending step, the first portion and the second portion of the pagemay be provided in a markup language. The second portion may compriseclient/browser interpretable language. In one embodiment, the languagecomprises JavaScript code.

[0016] In accordance with embodiments of the invention, receiving theselection may comprise receiving a modification of at least one itemselected from the group of an invoice item and a credit item. Further,calculating the payment amount may comprise offsetting modified amounts.Additionally, or alternatively, receiving the selection may comprisereceiving an invoice-to-credit-assignment. Moreover, returning theresponse may comprise returning an assignment vector, and receiving theselection may comprise receiving a selection of a payment instrument.Further, the step of calculating may comprise calculating credit as thedifference between a modified invoice amount and an entry invoiceamount, wherein the credit is communicated in a page during furtherexecution of the method.

[0017] Embodiments of the present invention also relate to a computerprogram product with computer instructions for causing one or morecomputer processors to execute the methods of the invention.

[0018] In accordance with still other embodiments of the invention, acomputer system is provided for preparing an electronic financialtransaction. The system comprises a first computer of a provider, asecond computer of an account institution, and a third computer of acustomer operated by a user. In the system, the first computer forwardsinvoice and credit information to the second computer prior to thepreparation of the transaction and, after the preparation of thetransaction, the second computer performs the transaction by deducting apayment amount from a customer account and adding the payment amount toa provider account.

[0019] The system may include various computer-implemented means. Forexample, the second computer may comprise means for sending a page tothe third computer to forward invoice and credit information in a firstportion of the page and to forward calculation instructions in a secondportion of the page. Further, the third computer may comprise means forinterpreting the first portion with a browser to present differentinvoice items and credit items on a screen. Additionally, oralternatively, the third computer may comprise means for receiving froma user of the third computer a selection of at least one invoice itemand of at least one credit item. The third computer may also comprisemeans for calculating the payment amount by offsetting the amounts ofthe invoice and credit items according to the instructions in the secondportion, and means for returning a response with the payment amount tothe second computer.

BRIEF DESCRIPTION OF THE DRAWINGS

[0020]FIG. 1 illustrates a simplified block diagram of an inventivecomputer network system;

[0021]FIG. 2 illustrates an overview of an exemplary system environmentfor preparing an electronic financial transaction;

[0022]FIG. 3 illustrates a simplified flowchart diagram of a firstmethod for preparing an electronic financial transaction;

[0023]FIG. 4 illustrates an overview of an exemplary system environmentfor presenting results of the electronic financial transaction;

[0024]FIG. 5 illustrates a simplified flowchart diagram of a secondmethod for processing data from the electronic financial transaction topresent results;

[0025]FIG. 6 illustrates a classification of monetary amounts;

[0026]FIG. 7 illustrates exemplary computers and program code;

[0027]FIG. 8 illustrates an exemplary overview of an assignment feature;

[0028]FIG. 9 illustrates an exemplary overview of the assignment in avariation;

[0029]FIG. 10 illustrates an exemplary overview over consecutiveexecutions of the first method, the transaction, and the second method;

[0030]FIG. 11 illustrates conventions for further figures;

[0031] FIGS. 12-16 illustrate exemplary screens during execution of thefirst method at consecutive time points; and

[0032] FIGS. 17-23 illustrate exemplary screens during execution of thesecond method.

COMPUTER SYSTEM IN GENERAL

[0033]FIG. 1 illustrates a simplified block diagram of an inventivecomputer network system 999 comprising a plurality of computers 900,901, 902 (or 90q, with q=0 . . . Q−1, Q any number).

[0034] Computers 900-902 are coupled via an inter-computer network 990.Computer 900 comprises a processor 910, a memory 920, a bus 930, and,optionally, an input device 940 and an output device 950 (I/O devices oruser interface 960). As illustrated, embodiments of the invention may beimplemented by a computer program product 100 (CPP), a program carrier970 and/or a program signal 980, collectively “program”.

[0035] With respect to computer 900, computer 901/902 is sometimesreferred to as “remote computer.” Computer 901/902 is, for example, aserver, a router, a peer device or other common network node, andtypically comprises many or all of the elements described relative tocomputer 900. Hence, elements 100 and 910-980 in computer 900collectively illustrate also corresponding elements 10q and 91q-98q(shown for q=0) in computers 90q.

[0036] Computer 900 is, for example, a conventional personal computer(PC), a desktop, a laptop, a hand-held device, a multiprocessorcomputer, a pen computer, a microprocessor-based or programmableconsumer electronics, a minicomputer, a mainframe computer, a personalmobile computing device, a mobile phone, a portable or stationarypersonal computer, a palmtop computer or the like.

[0037] Processor 910 is, for example, a central processing unit (CPU), amicro-controller unit (MCU), a digital signal processor (DSP), or thelike.

[0038] Memory 920 symbolizes elements that temporarily or permanentlystore data and instructions. Although memory 920 is convenientlyillustrated as part of computer 900, memory functions can also beimplemented in network 990, in computers 901/902 and in processor 910itself (e.g., a cache or register), or elsewhere. Memory 920 can be aread only memory (ROM), a random access memory (RAM), or a memory withother access options. Memory 920 may be physically implemented bycomputer-readable media, such as, for example: (a) magnetic media, likea hard disk, a floppy disk, or other magnetic disk, a tape, a cassettetape; (b) optical media, like an optical disk (e.g., a CD-ROM or digitalversatile disk—DVD); (c) semiconductor media, like DRAM, SRAM, EPROM,EEPROM, a memory stick, or by any other media, like paper.

[0039] Optionally, memory 920 is distributed across different media.Portions of memory 920 can be removable or non-removable. For readingfrom media and for writing in media, computer 900 may use devices wellknown in the art such as, for example, disk drives or tape drives.

[0040] Memory 920 stores support modules such as, for example, a basicinput output system (BIOS), an operating system (OS), a program library,a compiler, an interpreter, and a text-processing tool. Support modulesare commercially available and can be installed on computer 900 by thoseof skill in the art. For simplicity, these modules are not illustrated.

[0041] CPP 100 comprises program instructions and—optionally—data thatcause processor 910 to execute embodiments of the invention, includingsteps of the disclosed methods of the present invention. Method stepsare explained with more detail below. In other words, CPP 100 definesthe operation of computer 900 and its interaction in network system 999.For example and without the intention to be limiting, CPP 100 can beavailable as source code in any programming language, and as object code(“binary code”) in a compiled form. Persons of skill in the art can useCPP 100 in connection with any of the above-noted support modules (e.g.,a compiler, an interpreter, and/or an operating system).

[0042] Although CPP 100 is illustrated as being stored in memory 920,CPP 100 can be located elsewhere. CPP 100 can also be embodied incarrier 970.

[0043] Carrier 970 is illustrated outside computer 900. Forcommunicating CPP 100 to computer 900, carrier 970 may be convenientlyinserted into input device 940. Carrier 970 may be implemented as anycomputer readable medium, such as a medium largely explained above (cf.memory 920). Generally, carrier 970 is an article of manufacturecomprising a computer readable medium having computer readable programcode means embodied therein for executing embodiments of the invention,such as the methods of the present invention disclosed herein. Further,program signal 980 can also embody computer program 100. Signal 980travels on network 990 to computer 900.

[0044] Having described CPP 100, program carrier 970, and program signal980 in connection with computer 900 is convenient. Optionally, programcarrier 971/972 (not shown) and program signal 981/982 embody a computerprogram product (CPP) 101/102 to be executed by processor 911/912 (notshown) in computers 901/902, respectively.

[0045] Input device 940 symbolizes a device that provides data andinstructions for processing by computer 900. For example, device 940 maycomprise a keyboard, a pointing device (e.g., a mouse, a trackball,cursor direction keys), a microphone, a joystick, a game pad, a scanner,and/or a disk drive. Although the examples are devices with humaninteraction, device 940 can also operate without human interaction, suchas, a wireless receiver (e.g., with a satellite dish or terrestrialantenna), a sensor (e.g., a thermometer) and/or a counter (e.g., goodscounter in a factory). Input device 940 can also serve to read carrier970.

[0046] Output device 950 symbolizes a device that presents instructionsand data that have been processed. For example, a monitor or a display,a cathode ray tube (CRT), a flat panel display, a liquid crystal display(LCD), a speaker, a printer, a plotter, and/or a vibration alert device.Similar as above, output device 950 communicates with the user, but itcan also communicate with further computers.

[0047] Input device 940 and output device 950 can be combined into asingle device, and either device 940 or 950 can be provided optionally.

[0048] Bus 930 and network 990 provide logical and physical connectionsby conveying instruction and data signals. While connections insidecomputer 900 are conveniently referred to as “bus 930”, connectionsbetween computers 900-902 are referred to as “network 990”. Optionally,network 990 comprises gateways comprising computers that specialize indata transmission and protocol conversion.

[0049] Devices 940 and 950 may be coupled to computer 900 by bus 930 (asillustrated) or by network 990 (optional). While the signals insidecomputer 900 are mostly electrical signals, the signals in network maybe electrical, magnetic, optical or wireless (radio) signals.

[0050] Networking environments (such as network 990) are commonplace inoffices, enterprise-wide computer networks, intranets and the Internet(i.e., the World Wide Web). The physical distance between a remotecomputer and computer 900 is not important. Network 990 can be a wiredor a wireless network. To name a few network implementations, network990 may be, for example, a local area network (LAN), a wide area network(WAN), a public switched telephone network (PSTN), an IntegratedServices Digital Network (ISDN), an infra-red (IR) link, a radio link,like Universal Mobile Telecommunications System (UMTS), Global Systemfor Mobile Communication (GSM), Code Division Multiple Access (CDMA), ora satellite link.

[0051] Transmission protocols and data formats are known such as, forexample, transmission control protocol/internet protocol (TCP/IP), hypertext transfer protocol (HTTP), secure HTTP, wireless applicationprotocol, unique resource locator (URL), unique resource identifier(URI), hyper text markup language (HTML), extensible markup language(XML), extensible hyper text markup language (XHTML), wirelessapplication markup language (WML), Standard Generalized Markup Language(SGML), etc.

[0052] Interfaces coupled between the elements are also well known inthe art. For simplicity, interfaces are not illustrated. An interfacecan be, for example, a serial port interface, a parallel port interface,a game port, a universal serial bus (USB) interface, an internal orexternal modem, a video adapter, or a sound card.

[0053] Computers and programs are closely related. As used hereinafter,phrases, such as “the computer provides” and “the program provides”, areconvenient abbreviations to express actions by a computer that iscontrolled by a program.

DETAILED DESCRIPTION

[0054]FIG. 2 illustrates an overview of an exemplary system environmentfor implementing embodiments of the invention. For convenience ofexplanation, the following conventions are made: provider 01 is anorganization that provides service to customer 03 (e.g., an energysupplier supplying electricity to a private household); customer 03 is(a) a person or (b) an organization that receives the service. Accountinstitution 02 is an organization that arranges payment for the service(from customer 03 to provider 01). The user is a person (a) being thecustomer or (b) being associated with the customer.

[0055] The computers of FIG. 1 are conveniently classified into providercomputer 900, account computer 901 and customer computer 902. Thisclassification is convenient for explanation; computers 900 and 901 canbe combined as well; or computer functions can be distributed to furthercomputers.

[0056] Initially, provider computer 900 forwards invoice and creditinformation (I/C INFO) to account computer 901.

[0057] Performing a first server/client method of the present invention,

[0058] account computer 901 sends page 200 to customer computer 902 andthereby forwards I/C information in first portion 210 (of page 200) andforwards calculation instructions in second portion 220;

[0059] customer computer 902 uses a browser to interpret portion 210 (ofpage 200) to present different invoice items (e.g., “ALPHA 10

”, “BETA 20

”) and credit items (“CREDIT 5 Euro”) on screen 952;

[0060] the user (at computer 902) selects at least one invoice item(e.g., “BETA 20

”) and at least one credit item (e.g., “CREDIT 5

”);

[0061] the browser uses the instructions in portion 220 (of page 200) tocalculate a payment amount (P, e.g., 15

being the offset between the selected invoice item BETA and the selectedcredit item CREDIT); and

[0062] customer computer 902 returns response 250 with the paymentamount (P, e.g., “15

”) to account computer 901.

[0063] Transaction 600 has now been prepared according to a first method(cf. FIG. 3, 400) of the present invention, so that account computer 901performs transaction 600 by deducting P (e.g. 15

) from customer account 601 (C/A) and adding P to provider account 602(P/A).

[0064] Alternatively, the browser uses the instructions in portion 220(of page 200) to include a selection representation into response 250.The selection representation indicates the selected invoice item (e.g.,BETA) and the selected credit item (e.g., CREDIT). Calculating P isshifted to account computer 901.

[0065]FIG. 2 is also convenient to illustrate other conventions, asfurther described below.

[0066] An invoice list (IL) is a statement that is made available byprovider 01 to customer 03. The invoice list may list invoice items(e.g., “ALPHA 10

”, “BETA 20

”). In FIG. 2, the invoice list is illustrated as presented to the user(on screen 952). An invoice item generally is a representation of atleast a particular service together with a corresponding monetary amount(e.g., service ALPHA and amount 10

). The invoice item number (M) stands for the number of items on theinvoice list (FIG. 2: M=2).

[0067] A credit list is a statement that is made available by provider01 to customer 03 and that lists credit items. A credit item is arepresentation of a monetary amount that the provider credits to thecustomer for a particular action (e.g., 5

for overpayment). The credit item number (N) is the number of items onthe credit list (FIG. 2: N=1).

[0068] An invoice/credit list is a combination of invoice and creditlists for simultaneous presentation to the user (cf. screen 952 of FIG.2). Euro (

) is the exemplary currency used for explanation herein. Cents areconveniently not illustrated but can be added by those of skill in theart.

[0069] The sum invoice amount (ΣI) is the sum of the invoice amounts (I)to be paid, independent of selection (e.g., 10

+20

=30

). It is an advantage that the user selection determines which items areto be paid by transaction 600.

[0070] Likewise, the sum credit amount (ΣC) is the sum amount of allcredit items (e.g., 5

). The credit amount (C) is the amount of the selected credit items. Theadvantage applies likewise.

[0071] A selector is an interactive screen element presented by customercomputer 902 to the user. FIG. 2 symbolizes selectors by check boxes.Persons of skill in the art can implement the selectors otherwise, suchas by radio buttons, input fields, or by keys. In FIG. 2, there are 2invoice selectors for selecting an invoice item (e.g., only BETAselected) and a credit selector for selecting credit item (e.g., CREDIT5

selected).

[0072] The term browser-page stands for any document with browserreadable language (e.g., markup language or script language such asHTML, XML, Java, or JavaScript). The term browser presentationcollectively stands for lists, amount indicators, selectors and/or thelike that the browser displays on screen 952 to the user based on page200 with portions 210/220.

[0073]FIG. 3 illustrates a simplified flow chart diagram of an exemplarymethod 400 of the present invention. Method 400 is a method forpreparing an electronic financial transaction, wherein prior topreparing the transaction, first computer 900 of provider 01 forwardsinvoice and credit (I/C) information to second computer 901 of accountinstitution 02, and wherein after preparing, second computer 901performs the transaction by deducting a payment amount (P) from customeraccount 601 and adding the payment amount (P) to provider account 602.In the exemplary method, the step of preparing may comprise:

[0074] sending 410 page 200 to third computer 902 to forward invoice andcredit information in first portion 210 of the page 200 and to forwardcalculation instructions in second portion 220 of page 200;

[0075] interpreting 420 first portion 210 with a browser of thirdcomputer 902 to present different invoice items and credit items onscreen 952;

[0076] receiving 430 from the user of third computer 902 a selection ofat least one invoice item and of at least one credit item;

[0077] calculating 440 the payment amount (P) by offsetting the amountsof the invoice and credit items, thereby using the instructions insecond portion 220; and

[0078] returning 450 response 250 with the payment amount (P) to secondcomputer 901.

[0079]FIG. 4 illustrates an overview of an exemplary system environmentfor presenting results of the electronic financial transaction.Illustrated are account computer 901 (transaction 600, I/C), customercomputer 902, page 300 with first portion 310 (representations ofmonetary amounts) and second portion 320 (instructions), as well asscreen 952 with selector and lists.

[0080]FIG. 5 illustrates a simplified flowchart diagram of an exemplarymethod 500 for processing data from electronic financial transaction(600) with invoice items (I) and credit items (C). In other words, theexemplary method relates to a post-processing transaction 600.

[0081] In accordance with the exemplary method, computer 901 performsthe following steps: providing 510 page 300 (cf. FIG. 4) with aplurality of representations of monetary amounts relating to the invoiceitems and credit items (portion 310) and with instructions (portion320); and sending 520 page 300 to computer 902.

[0082] Computer 902 interprets the instructions with a browser toperform the following steps: receiving 530 a list selection from theuser; and, according to the selection, displaying 540 a list withinvoice items and credit items.

[0083] The following optional features are useful alone or incombination:

[0084] List Feature: presentation of different lists (L) on screen 952of computer 902 (cf. FIGS. 11-23);

[0085] Modification Feature: modification of invoice amounts (I) andcredit amounts (C): from entry (E) amount to modified (M) amount bydelta (D) amount (cf. FIGS. 11-23);

[0086] Multiple Instrument Feature: payment of single items by chargingmultiple payment instruments, payment instrument being any means forpaying (e.g., credit card, bank account, cash card, prepaid card), suchas BANK X or BANK Y (cf. FIGS. 12-16);

[0087] Business Rule Feature: calculation of payment amount underconsideration of credit amount, interest and the like, calculation atcomputer 902 or computer 901 (cf. FIG. 7);

[0088] Consecutive Transaction Feature: invoice or credit items withstates such as open (O) and residual (R) (cf FIG. 6, cf. FIGS. 11-23);and

[0089] Invoice-to-Credit Assignment Feature (FIGS. 8-9).

[0090] Letters in parenthesis are conveniently combined to form acronyms(e.g., E and I to EI). There is no need to display these acronyms orletters to the user. In other words, the acronyms in the FIGS. are onlyprovided for convenience of understanding.

[0091]FIG. 6 illustrates an exemplary classification for monetaryamounts. As indicated in the columns of FIG. 6, amounts may beclassified into amount types:

[0092] invoice amount (I): the amount that provider 01 charges tocustomer 03,

[0093] credit amount (C): the amount that provider 01 credits tocustomer 03, and

[0094] payment amount (P): the amount that is actually paid by customer03 during the transaction.

[0095] Provider 01 communicates I and C (i.e., I/C information) toaccount institution 02, and account institution 02 communicates I and Cto customer 03. Customer 03 communicates P to account institution 02 forpayment to provider 01 during the transaction. In terms of computers900-902, I and C may be part of page 200/300, and—implicit or explicit—Pmay be part of response 250 (optionally of page 300). Other arrangementsare also possible, consistent with the embodiments of the presentinvention.

[0096] Wherever possible, the explanations herein conveniently refer topositive amounts. However, it is within the scope of the presentinvention that amounts can be negative as well.

[0097] As indicated by the rows of FIG. 6, further classificationfollows some of the features:

[0098] Modification feature: entry amount (E) is the amount in I/Cinformation of page 200 sent from computer 901 to computer 902 (e.g., 10

, 20

and 5

for ALPHA, BETA, CREDIT, respectively). Modified amount (M) is theamount derived from E by user interaction in computer 902. Delta amount(D) is the arithmetic difference between entry amount E and modifiedamount M:

D=E−M.

[0099] E is also distinguished for I, C and P:

[0100] EI (entry invoice amount, e.g., 20

for BETA),

[0101] EC (entry credit amount, 5

as credit), and

[0102] EP (entry payment amount, e.g., EP=EI−EC), 15

payment).

[0103] Modified amount (M) is also distinguished for I, C and P:

[0104] MI (modified invoice amount, e.g., user reduces EI=20

to MI=18

),

[0105] MC (modified credit amount, e.g., user limits credit spendingfrom EC=5

to MC=2

), and

[0106] MP (modified payment amount, e.g., MP=MI−MC=18

−2

=16

).

[0107] Delta amount (D) is also distinguished for I, C and P:

[0108] DI=EI−MI (delta invoice amount),

[0109] DC=EC−MC (delta credit amount), and

[0110] DP=EP−MP (delta payment amount).

[0111] Delta amounts are calculated in computer 902 (e.g., by code inportion 220 of page 200) or in computer 901. The above definitions canbe applied to derive a modified amount M from an entry amount E and auser-defined delta amount D. This is convenient for optionalimplementations where the user indicates D instead of M. For example,for given EI=20

, the user indicates DI=2

, and MI=18

is calculated automatically.

[0112] In other words, D and M can be replaced. For convenience, theexplanation refers to M only (cf. examples in response 250).

[0113] D and M are used to calculate residual amounts.

[0114] Still referring to FIG. 6, page 200 communicates M invoice items(e.g., FIG. 2, M=2, ALPHA, BETA), and N credit items (e.g., FIG. 2,N=1). Sum amounts may be defined as follows:

[0115] ΣI (sum invoice amount) as the sum of all I(m) with m=1 to M, and

[0116] ΣC (sum credit amount) as the sum of all C(n) with n=1 to N.

[0117] Response 250 communicates Q payment items. A sum payment amountmay be defined as:

[0118] ΣP as the sum of all P(q) with q=1 to Q.

[0119] For symmetric payment assignment, M, N and Q are equal. Forasymmetric payment assignment, M, N and Q are not necessarily equal. Thenumber Q of payments is determined by a number of (m,n) pairs. Detailsare explained in connection with FIGS. 8-9.

[0120] Still referring to FIG. 6, for the consecutive transactionfeature, the following is defined: In repetitions of method 400,transaction 600, and method 500, entry amounts (E) are split intoportions for consecutive transactions. For example, an invoice amount(I) is open (O) (“unpaid”) as long as a first transaction is not yetcompleted. When the first transaction serves only a fraction of I, aresidual (R) amount becomes the entry amount (E). For convenience, openand residual amounts are distinguished by superscript O and R. Thedistinction is made for I and C.

[0121] E^(O)I (entry open invoice amount), the invoice amount in page200 during the first execution of method 400 (e.g., E^(O)I=20

, BETA).

[0122] E^(R)I (entry residual invoice amount), the invoice amount inpage 200 during the second execution of method 400 (e.g., E^(R)I=2

if MI=18

was initially paid, BETA).

[0123] E^(O)C (entry open credit amount), the credit amount in page 200during the first execution of method 400 (e.g., 5

).

[0124] E^(R)C (entry residual credit amount), the credit amount in page200 during a second or further execution of method 400 (e.g., EC=3

).

[0125] Preferably, the amount classification remains hidden from theuser.

[0126]FIG. 7 illustrates an example of computers 901 and 902 withprogram code (“CODE”) for executing methods 400 and 500. The code ispart of CPP 101 and 102 in computers 901 and 902, respectively.Optionally, CPP 102 is communicated to computer 902 from computer 901,for example, in portion 220 of page 200. Java script, Java applets orother browser interpretable code is advantageously used in computer 902.Calculation steps, for example, to calculate P are performed either bycomputer 901 alone, by computer 902 alone, or by computers 901 and 902in combination.

[0127] Business-rule feature: A business rule is any predefined rule forcalculating P, for example, the one-to-one rule with P being thedifference between invoice amount I and credit amount C.

[0128] This one-to-one rule can be applied to the classification of FIG.6, for example:

[0129] ΣP=ΣI−ΣC (sum payment amount), and

[0130] P=I−C (any payment amount).

[0131] Further rules can be introduced:

[0132] discount calculation rule, e.g.,

[0133] P=E−DISCOUNT,

[0134] time rule, e.g., DISCOUNT as a function of time,

[0135] interest rule, consideration of accumulated interest over time,or

[0136] deriving P from a modified amount (M).

[0137] A rule for calculating credit is, for example:

[0138] C=M−E (for details cf. FIGS. 11-23).

[0139] A rule for calculating modified amount is, for example:

[0140] M=E*95% or E*105 (pay 5% less or more depending on availablecredit).

[0141] Persons of skill in the art can introduce still further ruleswithout departing from the scope of the invention.

[0142] FIGS. 8-9 illustrate exemplary overviews related to theinvoice-to-credit assignment feature.

[0143] Generally, the user assigns invoice amounts I to credit amountsC. More specifically, the user may assign a number of M invoice amountsI(m) to a number of N credit amounts C(m). In the example, both numbersare equal: M=N.

[0144] The figures indicate each assignment by a separate arrow and bythe payment amount (P(q) or P(m,n)) calculated, for example, accordingto P=I−C (one-to-one rule). The plurality of (m,n) indices form anassignment vector.

[0145] The button row indicates sum amounts ΣI, ΣP and ΣC. Both figuresconveniently use the same exemplary amounts: 20

, 10

, 40

and 30

as I (invoice) and 30

, 10

, 20

and 20

as C (credit). In both cases, customer 03 has to pay ΣI=100

. Using credits with ΣC=80

, customer 03 pays only ΣP=20

.

[0146] The assignments are classified into symmetric assignment withP(q) (FIG. 8) and asymmetric assignment with P(m,n) (FIG. 9).

[0147] For example in FIG. 8:

[0148] P(1)=−10

is the amount to be paid for invoice item 1 (I(1)=20

) by using credit item 1 (C(1)=30

);

[0149] P(2)=0

is the amount to be paid for invoice item 2 (I(2)=10

) by using credit item 2 (C(2)=10

);

[0150] P(3)=20

is the amount to be paid for invoice item 3 (I(3)=40

) by using credit item 3 (C(3)=20

); and

[0151] P(4)=10

is the amount to be paid for invoice item 4 (I(4)=30

) by using credit item 4 (C(4)=20

).

[0152] The assignment vector is:

[0153] [(m,n)]=[(1,1), (2,2), (3,3), (4,4)], which may be simplified to:

[0154] [q]=[1, 2, 3, 4].

[0155] For example in FIG. 9:

[0156] P(1,4)=0

is the amount to be paid for invoice item 1 (I(4)=20

) by using credit item 4 (C(4)=20

);

[0157] P(2,2)=0

is the amount to be paid for invoice item 2 (I(2)=10

by using credit item 2 (C(2)=10

);

[0158] P(3,3)=20

is the amount to be paid for invoice item 3 (I(3)=40

) by using credit item 3 (C(3)=20

); and

[0159] P(4,1)=0

is the amount to be paid for invoice item 4 (I(4)=30

) by using credit item 1 (C(1)=30

).

[0160] The assignment vector is:

[0161] [(m,n)]=[(1,4), (2,2), (3,3), (4,1)].

[0162] The assignment vector (e.g., either of FIG. 8 or 9) isconveniently communicated from computer 902 to computer 901 in response250. Preferably, the assignment is determined through user interaction.The following description refers to FIG. 9 under the assumption that 4screens with checkboxes are displayed one after the other. Optionally,amounts are displayed to the user next to the checkboxes.

[0163] Screen with check boxes for I(1), I(2), I(3), I(4), C(1), C(2),C(3) and C(4). The user selects I(1) and C(4). The first vector elementis determined as (1,4).

[0164] Screen with remaining check boxes for I(2), I(3), I(4), C(1),C(2) and C(3). The user selects I(2) and C(2). The second vector elementis determined as (2,2).

[0165] Screen with remaining check boxes for I(3), I(4), C(1), and C(3).The user selects I(3) and C(3). The third vector element is determinedas (3,3).

[0166] Screen with remaining check boxes for I(4) and C(1). The userselects them. The fourth vector element is determined as (4,1).

[0167] Modifying the amount accordingly is optional (modificationfeature, E to M). For example, the screen could have input fields toinvite the user to alter entry invoice amounts (EI) to modified invoiceamounts (MI).

[0168]FIG. 10 illustrates an exemplary overview over consecutiveexecutions of method 400, transaction 600, and method 500.

[0169] Vertical lines symbolize computers 901 and 902; a diamondsymbolizes transaction 600 (on computer 901). Arrows indicate thefollowing steps:

[0170] sending page 200 (method 400),

[0171] returning response 250 (method 400), and

[0172] sending page 300 (method 500).

[0173] MARCH, APRIL, MAY, JUNE, JULY, AUGUST and subscripts 3, 4, 5, 6,7, 8, respectively, indicate consecutive time points of methodexecution.

[0174] Jan, Feb, Mar, Apr, May, Jun, Jul (or “ . . . ”) indicateservices provided by provider 01 to customer 03. These 3-letter wordsappear on the list and also serve as indices (instead of m or n).

[0175] Page 200 has EI( . . . ) (entry invoice amounts) and EC( . . . )(entry credit amounts) corresponding to the service (by provider 01).Both EI( . . . ) and EC( . . . ) can be open (O) or residual (R).

[0176] Response 250 has MI( . . . ) (modified invoice amounts) and MC( .. . ) (modified credit amounts).

[0177] Page 300 has amounts to be presented, such as payments amounts P(. . . ).

[0178] It is assumed that provider 01 has already forwarded I/C toaccount institution 02 for January and February services to customer 03.Method 500 can be executed at any time point; the illustration at AUGUSTis a convenient example.

[0179] While pages 200, 300 and response 250 remain hidden from theuser, corresponding example for screen 952 of computer 902 at timepoints MARCH to AUGUST are illustrated in the following figures.

[0180]FIG. 11 provides illustration conventions for FIGS. 12-21.

[0181] Plain-line frames illustrate screen 952 as presented to the userwith selectors and lists (L). The selectors are symbolized by a checkbox, by a radio button and by a register tab.

[0182] Dashed-line frames illustrate acronyms for content of page 200,response 250 or page 300, usually hidden from the user. The acronymscorrespond to these in FIG. 10.

[0183] FIGS. 12-16 represent exemplary repetitions of method 400 fromMARCH to JULY. Illustrated are (list feature):

[0184] EIL (entry invoice list),

[0185] ECL (entry credit list),

[0186] MIL (modified invoice list),

[0187] MCL (modified credit list), and

[0188] BL (bank list).

[0189] An EIL becomes a MIL when the user modifies at least one invoiceamount. An ECL becomes a MCL when the user modifies at least one creditamount (modification feature). EIL and ECL are preferably presentedsimultaneously; MIL and MCL are also preferably presentedsimultaneously.

[0190] Optionally, items are automatically selected if the user modifiesthe amount of the item. The order in time of modifying (EI to MI, EC toMC) and of selecting is not important.

[0191] After modification/selection, P (payment amount) is calculated(business rule feature), and BL is presented to determine the preferredpayment instrument (multiple instrument feature).

[0192] Although illustrated together, EIL/ECL, MIL/MCL and BL areconveniently presented to the user consecutively.

[0193] Texts are presented to assist the user, for example, by:

[0194] “Jan”, “Feb” etc. to identify invoice or credit items,

[0195] “INVOICE” for an invoice list (EIL, MIL),

[0196] “CREDIT” for a credit list (ECL, MCL),

[0197] “Total to pay” for ΣEI minus ΣEC,

[0198] “Decided to pay” for ΣMI minus ΣMC, and

[0199] “BANK” for indicating the payment instrument, for example, BANK Xor BANK Y.

[0200] Text is accompanied by amounts (EI, EC, MI, MC, Σ). Preferably,sum amounts and payment amounts for display on screen 952 are calculatedby computer 902. (Amounts for transaction 600 are optionally calculatedby computer 901.)

[0201] As indicated in the dashed frames, data from page 200 is:

[0202] EI (entry invoice amount), and

[0203] EC (entry credit amount).

[0204] Data going into response 250 is:

[0205] MI (modified invoice amount),

[0206] MC (modified credit amount), and

[0207] bank indicator X or Y.

[0208]FIG. 12 illustrates a MARCH time point. Customer 03 using BANK Xpartially pays for Jan and Feb services. In other words, customer 03pays less than required.

[0209] lists: EIL, MIL, and BL.

[0210] entry invoice amount:

[0211] E^(O)I(Jan)₃=200

(original)

[0212] E^(O)I(Feb)₃=100

(original)

[0213] sum entry invoice amount (“Total to pay”) $\begin{matrix}{{\Sigma \quad {EI}_{3}} = {{200\quad } + {100\quad }}} \\{= {300\quad }}\end{matrix}$

[0214] modified invoice amounts:

[0215] MI(Jan)₃=130

[0216] MI(Feb)₃=90

[0217] ΣMI₃=130

+90

=220

[0218] delta amounts: $\begin{matrix}{{{DI}\quad ({Jan})_{3}} = {{{EI}\quad ({Jan})} - {{MI}\quad ({Jan})}}} \\{\quad {= {{200\quad } - {130\quad }}}} \\{\quad {= {70\quad }}} \\{{{DI}\quad ({Feb})_{3}} = {{{EI}\quad ({Feb})} - {{MI}\quad ({Feb})}}} \\{\quad {= {{100\quad } - {90\quad }}}} \\{\quad {= {10\quad }}} \\{{\Sigma \quad {DI}_{3}} = {{\Sigma \quad {EI}} - {\Sigma \quad {MI}}}} \\{\quad {= {{300\quad } - {220\quad }}}} \\{\quad {= {80\quad }}}\end{matrix}$

[0219] business rule: one-to-one $\begin{matrix}{{\Sigma \quad P_{3}} = {\Sigma \quad {MI}_{3}}} \\{= {220\quad }}\end{matrix}$

[0220] Bank selection: X

[0221]FIG. 13 illustrates a APRIL time point. Using BANK Y, customer 03completely pays the residual amounts for Jan and Feb services, partiallypays for Mar service. Again, customer 03 pays less than required.

[0222] lists: EIL, MIL and BL

[0223] entry invoice amount:

[0224] E^(R)I(Jan)₄=70

(residual, E^(R)I(Jan)₄=DI(Jan)₃)

[0225] E^(R)I(Feb)₄=10

(residual, E^(R)I(Feb)₄=DI(Feb)₃)

[0226] E^(O)I(Mar)₄=80

(original) $\begin{matrix}{{\Sigma \quad {EI}_{4}} = {{E^{R}I\quad ({Jan})_{4}} + {E^{R}I\quad ({Feb})_{4}} + {E^{O}I\quad ({Mar})_{4}}}} \\{= {{70\quad } + {10\quad } + {80\quad }}} \\{= {160\quad }}\end{matrix}$

[0227] modified invoice amount:

[0228] MI(Jan)₄=70

[0229] MI(Feb)₄=10

[0230] MI(Mar)₄=70

[0231] business rule: one-to-one $\begin{matrix}{P_{4} = {\Sigma \quad {MI}_{4}}} \\{= {150\quad }}\end{matrix}$

[0232] Bank selection: Y

[0233]FIG. 14 illustrates a MAY time point. Using BANK X, customer 03completely pays the residual amount for Mar service and overpays for Aprservice.

[0234] lists: EIL, MIL and BL

[0235] entry invoice amounts:

[0236] E^(R)I(Mar)₅=10

(residual, E^(R)I(Mar)₅=DI(Mar)₄)

[0237] E^(O)I(Apr)₅=50

(open) $\begin{matrix}{{\Sigma \quad {EI}_{5}} = {{10\quad } + {50\quad }}} \\{= {60\quad }}\end{matrix}$

[0238] modified invoice amounts:

[0239] MI(Mar)₅=10

[0240] MI(Apr)₅=90

(i.e. 40

more than required)

[0241] ΣMI₅=10

+90

=100

[0242] business rule: one-to-one $\begin{matrix}{{\Sigma \quad P_{5}} = {\Sigma \quad {MI}_{5}}} \\{= {100\quad }}\end{matrix}$

[0243] bank selection: X

[0244]FIG. 15 illustrates a JUNE time point. Using BANK X and creditfrom overpayment (Apr service), customer 03 partially pays for Mayservice. Customer 03 pays less than required.

[0245] lists: EIL/ECL, MIL/MCL, BL

[0246] entry invoice amount (in EIL):

[0247] E^(O)I(May)₆=50

(original)

[0248] entry credit amount (in ECL):

[0249] E^(O)C(Apr)₆=40

(original, MI(Apr)₅−EI(Apr)₅)

[0250] modified invoice amount (in MIL):

[0251] MI(May)₆=40

[0252] modified credit amount (in MCL):

[0253] MC(Apr)₆=10

(i.e. not using 30

)

[0254] business rule: one-to-one $\begin{matrix}{{\Sigma \quad P_{6}} = {{\Sigma \quad {MI}_{6}} - {\Sigma \quad {MC}_{6}}}} \\{= {{{MI}\quad ({May})_{6}} - {{MC}\quad ({Apr})_{6}}}} \\{= {30\quad }}\end{matrix}$

[0255] Bank selection: X

[0256]FIG. 16 illustrates a JULY time point. Still using credit fromoverpayment (Apr service), customer 03 completely pays the residual forMay service and partially pays for Jun service. Customer 03 pays lessthan required.

[0257] lists: EIL/ECL, MIL/MCL

[0258] entry invoice amount (in EIL):

[0259] E^(R)I(May)₇=10

(residual)

[0260] E^(O)I(Jun)₇=40

(original)

[0261] entry credit amount (in ECL):

[0262] E^(R)C(Apr)₇=30

(residual, E^(O)C(Apr)₆−MC(Apr)₆=40

−10 E)

[0263] modified invoice amount (in MIL):

[0264] MI(May)₇=10

(unchanged)

[0265] MI(Jun)₇=20

(reduced from 40

)

[0266] modified credit amount (in MCL):

[0267] MC(Apr)₇=10

(unchanged, i.e. using the credit completely)

[0268] business rule: one-to-one $\begin{matrix}{{\Sigma \quad P_{7}} = {{\Sigma \quad {MI}_{7}} - {\Sigma \quad {MC}_{7}}}} \\{= {{{MI}\quad ({May})_{7}} + {{MI}\quad ({Jun})_{7}} - {{MC}\quad ({Apr})_{7}}}} \\{= {{10\quad } + {20\quad } - {30\quad }}} \\{= {0\quad .}}\end{matrix}$

[0269] FIGS. 17-23 illustrate an exemplary execution of method 500 inAUGUST.

[0270]FIG. 17 illustrates a list selector, for example, register cardswith tab for invoice items, credit items, or payment overviews. The useris invited to select any list (cf. step 530 receiving list selection)for example:

[0271] OPEN INVOICES (cf. FIG. 18)

[0272] PAID INVOICES (cf. FIG. 19)

[0273] USED CREDITS (cf. FIG. 20)

[0274] OPEN CREDITS (cf. FIG. 21)

[0275] PAYMENTS PER ITEM (cf. FIG. 22)

[0276] PAYMENTS PER PAY DATE (cf. FIG. 23)

[0277] Information needed to provide the lists are forwarded in page 300(step sending page) from computer 901 to computer 902. As in step 540,the lists are displayed as follows.

[0278]FIG. 18 illustrates OIL (open invoice list) listing invoice itemsfor that payment by customer 03 is outstanding (“My Open Bills”):

[0279] ERI(Jun)₈ (payment for Jun as residual E^(O)I(Jun)₇−MI (Jun)₇).

[0280]FIG. 18 illustrates PIL (paid invoice list) listing invoice itemsfor that customer 03 has already paid. For services Jan to May:

[0281] MI(Jan)₃+MI(Jan)₄

[0282] MI(Feb)₃+MI(Feb)₄

[0283] MI(Mar)₄+MI(Mar)₅

[0284] MI(Apr)₅−credit

[0285] MI(May)₆+MI(May)₇

[0286] The amount for unpaid service Jun is not illustrated.

[0287]FIG. 20 illustrates used CL (credit list) listing credit itemsthat customer 03 has acquired and used. In the example, credit wascalculated as: $\begin{matrix}{{{ERC}\quad ({Apr})_{6}} = {{{MI}\quad ({Apr})_{5}} - {E^{O}I\quad ({Apr})_{5}}}} \\{= {{90\quad } - {50\quad }}} \\{= {40\quad }}\end{matrix}$

[0288] Credit usage was distributed to:

[0289] MC(Apr)₆=10

(JUNE) for service May (cf. FIG. 15),

[0290] MC(Apr)₇=10

+20

for service May and June, (cf. FIG. 16).

[0291]FIG. 21 illustrates open credits, i.e. credits that are stillavailable. In the example, all credit was used.

[0292] Convenient is the indication of:

[0293] the origin of the credit (e.g., overpayment for a certainservice),

[0294] C (credit amount), and

[0295] possible usage (conveniently also in combination with a graphicalassignment as in FIGS. 8-9).

[0296]FIG. 22 illustrates an overview about payments made between MARCHand JULY. Columns indicate:

[0297] service by provider 01 (e.g., Jan to Jun),

[0298] pay status (Yes=I completely paid),

[0299] pay date (e.g., months MARCH to JULY),

[0300] BANK as payment instrument (X, Y and also CREDIT), and

[0301] amount that was paid (i.e., MI).

[0302] Convenient is an indication of credit generation (Apr in MAY) andcredit spending (May/Jun in JUNE/JULY). Optionally, sorting schemes areprovided so that the user can, for example, sort the overview accordingto pay date (e.g., ascending from MARCH), BANK, amounts (e.g., startingwith the largest) or the like.

[0303]FIG. 23 illustrates an overview about payments organized accordingto pay date from MARCH to JULY. In other words, the figure informs abouttransactions 600 that have followed method 400.

[0304] Based on substantially the same data as for FIG. 22, the figuresindicates also optionally indicates items, bank, amount per item, andsum amounts.

[0305] Persons of skill in the art can introduce various modificationsto FIGS. 18-23. From the great variety of modifications, only some canbe named here, for example:

[0306] splitting into partial amounts (e.g., PIL in FIG. 18, separatelydisplay MI(Jan)₃ and MI(Jan)₄);

[0307] indicating transaction dates (e.g., writing MARCH and APRIL);

[0308] introducing warnings to unpaid items;

[0309] having a list of residual invoice and credit items;

[0310] calculating credit amounts during selection so that the user seespotential benefits;

[0311] calculating P in computer 902 in parallel to computer 901 toinform the user;

[0312] displaying due dates, calendar dates by that provider 01 expectscompletion of transaction 600;

[0313] displaying available dates, calendar dates from that provider 01provides credit in the future;

[0314] simulating bank statements, for example, listing thetransactions, e.g., from BANK X (MARCH, MAY) and BANK Y (APRIL); and

[0315] searching items according to predefined criteria, such as status(e.g., transaction completed/“processed”), payment instrument (e.g.,BANK X or Y), time period (e.g., last 12 months).

[0316] For such extra functionality, persons of skill in the art can addaction control buttons or other browser control means.

[0317] It is an advantage that commercially available browser can beused in computer 902; in other words, extra software on computer 902 isnot required.

References

[0318] Σ sum

[0319] (m,n) invoice-to-credit assignment

[0320]

Euro

[0321]01 provider

[0322]02 account institution

[0323]03 customer

[0324]10x computer program product

[0325]200, 300 page

[0326]210, 310 first portion

[0327]220, 320 second portion

[0328]250 response

[0329]400, 4xx method for preparing

[0330]500, 5xx method for processing

[0331]600 transaction

[0332]601 customer account (C/A)

[0333]602 provider account (P/A)

[0334]900 provider computer

[0335]901 account computer

[0336]902 customer computer

[0337]952 screen

[0338]9xx computer components

[0339] B, X, Y bank

[0340] C, n, N credit, index and number

[0341] E entry

[0342] I, m, M invoice, index, number

[0343] L, list

[0344] M, modified

[0345] O, open

[0346] P, q, Q payment, index and number

[0347] R, residual

1. A method for preparing an electronic financial transaction, whereinprior to preparing the transaction, a first computer of a providerforwards invoice and credit information to a second computer of anaccount institution, and wherein after preparing, the second computerperforms the transaction by deducting a payment amount from a customeraccount and adding the payment amount to a provider account, the methodof preparing comprising: sending a page to the third computer to forwardinvoice and credit information in a first portion of the page and toforward calculation instructions in a second portion of the page;interpreting the first portion by a browser of the third computer topresent different invoice items and credit items on a screen; receivingfrom a user of the third computer a selection of at least one invoiceitem and of at least one credit item; calculating the payment amount byoffsetting the amounts of the invoice and credit items based on theinstructions in the second portion; and returning a response with thepayment amount to the second computer.
 2. The method of claim 1, whereincalculating comprises evaluating the payment amount under considerationof an available date of at least one credit item.
 3. The method of claim1, wherein sending comprises providing the first portion and the secondportion of the page in a markup language.
 4. The method of claim 1,wherein the second portion of the page comprises a client/browserinterpretable language.
 5. The method of claim 4, wherein the languagecomprises JavaScript code.
 6. The method of claim 1, wherein receiving aselection comprises receiving a modification of at least one itemselected from the group of an invoice item and a credit item.
 7. Themethod of claim 6, wherein calculating the payment amount comprisesoffsetting modified amounts.
 8. The method of claim 1, wherein receivingthe selection comprises receiving an invoice-to-credit-assignment. 9.The method of claim 8, wherein returning the response comprisesreturning an assignment vector.
 10. The method of claim 1, whereinreceiving the selection comprises receiving a selection of a paymentinstrument.
 11. The method of claim 1, wherein calculating comprisescalculating a credit as the difference between a modified invoice amountand an entry invoice amount, wherein the credit is communicated in apage during further execution of the method.
 12. A computer programproduct with computer instructions for causing one or more computerprocessors to execute the method according to any one of claims 1-11.13. A computer system for preparing an electronic financial transaction,the system comprising a first computer of a provider, a second computerof an account institution, and a third computer of a customer operatedby a user, wherein the first computer, prior to the preparation of thetransaction, forwards invoice and credit information to the secondcomputer, and wherein, after preparation of the transaction, the secondcomputer performs the transaction by deducting a payment amount from acustomer account and adding the payment amount to a provider account,the system further comprising: means for sending a page to the thirdcomputer to forward invoice and credit information in a first portion ofthe page and forward calculation instructions in a second portion of thepage; means for interpreting the first portion with the third computerto present different invoice items and credit items on a screen; meansfor receiving from a user of the third computer a selection of at leastone invoice item and of at least one credit item; means for calculatingthe payment amount by offsetting the amounts of the invoice and credititems in accordance with the instructions in the second portion; andmeans for returning a response with the payment amount to the secondcomputer.
 14. The computer system of claim 13, wherein the means forsending the page comprises means for sending the page from the secondcomputer to the third computer.
 15. The computer system of claim 13,wherein the means for sending the page comprises means for providing thefirst portion and the second portion of the page in a markup language.16. The computer system of claim 13, wherein the means for interpretingthe first portion of the page comprises a browser of the third computer.17. The computer system of claim 13, wherein the means for receiving aselection comprises means for receiving a modification of at least oneitem selected from the group of an invoice item and a credit item. 18.The computer system of claim 17, wherein the means for calculatingcomprises means for offsetting modified amounts.
 19. The computer systemof claim 13, wherein the means for receiving the selection comprisesmeans for receiving an invoice-to-credit-assignment, and wherein themeans for returning the response comprises means for returning anassignment vector.
 20. The computer system of claim 13, wherein themeans for calculating comprises means for calculating a credit as thedifference between a modified invoice amount and an entry invoiceamount.